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Abstract 


This document describes the use of keyed SHA1 with the IP 
Authentication Header. 
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Introduction 


The Authentication Header (AH) [RFC-1826] provides integrity and 
authentication for IP datagrams. This specification describes the AH 
use of keys with the Secure Hash Algorithm (SHA1) [FIPS-180-1]. This 
SHA1-IP-MAC algorithm uses a leading and trailing key (a variant of 
the "envelope method"), with alignment padding between both keys and 
data. 


It should be noted that this document specifies a newer version of 
SHA than that described in [FIPS-180], which was flawed. The 
older version is not interoperable with the newer version. 


This document assumes that the reader is familiar with the related 
document "Security Architecture for the Internet Protocol" [RFC- 
1825], that defines the overall security plan for IP, and provides 
important background for this specification. 


1. Keys 


The secret authentication key shared between the communicating 
parties SHOULD be a cryptographically strong random number, not a 
guessable string of any sort. 


The shared key is not constrained by this transform to any particular 
size. Lengths of 160-bits (20 octets) MUST be supported by the 
implementation, although any particular key may be shorter. Longer 
keys are encouraged. 


-2. Data Size 


SHA1’s 160-bit output is naturally 32-bit aligned. However, many 
implementations require 64-bit alignment of the following headers. 


Therefore, several options are available for data alignment (most 
preferred to least preferred): 


1) only the most significant 128-bits (16 octets) of output are used. 


2) an additional 32-bits (4 octets) of padding is added before the 
SHA1 output. 


3) an additional 32-bits (4 octets) of padding is added after the 
SHA1 output. 


4) the SHA1 output is variably bit-positioned within 192-bits (24 
octets). 
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The size and position of the output are negotiated as part of the key 
management. Padding bits are filled with unspecified implementation 
dependent (random) values, which are ignored on receipt. 


Discussion: 


Although truncation of the output for alignment purposes may 
appear to reduce the effectiveness of the algorithm, some analysts 
of attack verification suggest that this may instead improve the 
overall robustness [PO95a]. 


1.3. Performance 


Preliminary results indicate that SHAl is 62% as fast as MD5, and 80% 
as fast as DES hashing. That is: 


SHA1l < DES < MD5 


This appears to be a reasonable performance tradeoff, as SHAl 
internal chaining is significantly longer than either DES or MD5: 


DES < MD5 < SHA1 


Nota Bene: 
Suggestions are sought on alternative authentication algorithms 
that have significantly faster throughput, are not patent- 
encumbered, and still retain adequate cryptographic strength. 


2. Calculation 


The 160-bit digest is calculated as described in [FIPS-180-1]. A 
portable C language implementation of SHAl is available via FTP from 
ftp://rand.org/pub/jim/sha.tar.gz. 


The form of the authenticated message is: 
SHA1( key, keyfill, datagram, datafill, key, shalfill ) 


First, the variable length secret authentication key is filled to the 
next 512-bit boundary, using the same pad-with-length technique 
defined for SHAl. The padding technique includes a length that 
protects arbitrary length keys. 


Next, the filled key is concatenated with (immediately followed by) 
the invariant fields of the entire IP datagram (variant fields are 
zeroed). This is also filled to the next 512-bit boundary, using the 
same pad-with-length technique defined for SHAl. The length includes 
the leading key and data. 
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Then, the filled data is concatenated with (immediately followed by) 
the original variable length key again. A trailing pad-with-length 
to the next 512-bit boundary for the entire message is added by SHA1 
itself. 


Finally, the 160-bit SHAl digest is calculated, and the result is 
inserted into the Authentication Data field. 


Discussion: 


The leading copy of the key is padded in order to facilitate 
copying of the key at machine boundaries without requiring re- 
alignment of the following datagram. Filling to the SHA1 block 
size also allows the key to be prehashed to avoid the physical 
copy in some implementations. 


The trailing copy of the key is not necessary to protect against 
appending attacks, as the IP datagram already includes a total 
length field. It reintroduces mixing of the entire key, providing 
protection for very long and very short datagrams, and robustness 
against possible attacks on the IP length field itself. 


When the implementation adds the keys and padding in place before 


and after the IP datagram, care must be taken that the keys and/or 
padding are not sent over the link by the link driver. 
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A. Changes 
Changes from RFC 1852: 
Use of SHA1 term (as always intended). 
Added shortened 128-bit output, and clarify output text. 
Added tradeoff text. 
Changed padding technique to comply with Crypto '95 recommendations. 
Updated references. 
Updated contacts. 


Minor editorial changes. 
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Security Considerations 


Users need to understand that the quality of the security provided by 
this specification depends completely on the strength of the SHA1 
hash function, the correctness of that algorithm’s implementation, 
the security of the key management mechanism and its implementation, 
the strength of the key, and upon the correctness of the 
implementations in all of the participating nodes. 


The SHA algorithm was originally derived from the MD4 algorithm 
[RFC-1320]. A flaw was apparently found in the original 
specification of SHA [FIPS-180], and this document specifies the use 
of a corrected version [FIPS-180-1]. 


At the time of writing of this document, there are no known flaws in 
the SHA1 algorithm. That is, there are no known attacks on SHA1 or 
any of its components that are better than brute force, and the 160- 
bit hash size of SHAl is substantially more resistant to brute force 
attacks than the 128-bit hash size of MD4 and MD5. 


However, as the flaw in the original SHA1 algorithm shows, 
cryptographers are fallible, and there may be substantial 
deficiencies yet to be discovered in the algorithm. 
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This document is a submission to the IP Security Working Group of the 
Internet Engineering Task Force (IETF). The working group can be 
contacted via the current chairs: 


Questions about this document can also be directed to: 
Perry Metzger 

Piermont Information Systems Inc. 
160 Cabrini Blvd., Suite #2 

New York, NY 10033 

EMail: perry@piermont.com 

William Allen Simpson 

DayDreamer 

Computer Systems Consulting Services 
1384 Fontaine 

Madison Heights, Michigan 48071 


EMail: wsimpson@UMich.edu 
wsimpson@GreenDragon.com (preferred) 


Editor’s Note 


This paper was originally submitted May 1, 1996. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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